home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000139_owner-urn-ietf _Tue Nov 12 13:24:57 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA23052 for urn-ietf-out; Tue, 12 Nov 1996 13:24:57 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA23047 for <urn-ietf@services.bunyip.com>; Tue, 12 Nov 1996 13:24:54 -0500
  3. Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA03711  (mail destined for urn-ietf@services.bunyip.com); Tue, 12 Nov 96 13:24:51 -0500
  5. Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id LAA09242; Tue, 12 Nov 1996 11:24:21 -0700 (MST)
  6. Message-Id: <2.2.32.19961112183238.0070c654@acl.lanl.gov>
  7. X-Sender: rdaniel@acl.lanl.gov
  8. X-Mailer: Windows Eudora Pro Version 2.2 (32)
  9. Mime-Version: 1.0
  10. Content-Type: text/plain; charset="us-ascii"
  11. Date: Tue, 12 Nov 1996 11:32:38 -0700
  12. To: Harald.T.Alvestrand@uninett.no
  13. From: Ron Daniel <rdaniel@acl.lanl.gov>
  14. Subject: Re: [URN] HTTP resolution protocol
  15. Cc: urn-ietf@bunyip.com
  16. Sender: owner-urn-ietf@services.bunyip.com
  17. Precedence: bulk
  18. Reply-To: Ron Daniel <rdaniel@acl.lanl.gov>
  19. Errors-To: owner-urn-ietf@bunyip.com
  20.  
  21. I'm revising the "Conventions for the Use of HTTP for URN Resolution"
  22. draft that I sent to the list awhile back. Before I do so I wanted to
  23. ask the list about one point in Harald's last message on the subject.
  24.  
  25. Thus spoke Harald.T.Alvestrand@uninett.no (at least at 02:44 PM 11/4/96 +0100)
  26. >(Warning: I'm coming into this without reading the entire debate...)
  27. >
  28. >I like the idea that HTTP GET is an URI to MIME object resolution
  29. >protocol. It either fails or returns a MIME object.
  30. >
  31. >But the scheme of service:/uri would IMHO require registering
  32. >N2L, N2Ls, N2C and so on as URI types; this sounds wrong to me.
  33.  
  34. Agreed.
  35.  
  36. >
  37. >If we want a resolution CONVENTION, it seems to me that the right
  38. >convention is "GET /resolve/N2L/<uri>" (mimicking a CGI-BIN script).
  39. >If we want a resolution STANDARD, it seems to me that the right
  40. >thing is "N2L <uri> HTTP/1.1"
  41.  
  42. I tend to agree that a true resolution STANDARD should define the
  43. new HTTP Methods. However, I was shooting for a simple CONVENTION
  44. for people to follow. The primary goal was to make it easy to retrofit
  45. URN resolution onto existing web servers.
  46.  
  47. That is the tack that I will continue to follow if there is not a
  48. massive outpouring of derision from the list.
  49.  
  50. I will change Harald's suggestion from GET /resolve/<service>/<uri>
  51. to GET /uri-res/<service>/<uri> because an Alta Vista search turned
  52. up some instances of /resolve in existing URLs, but no instances of
  53. /uri-res.
  54.  
  55. >For handing back lists of things, mimic the responses that were put
  56. >into HTTP/1.1 for content negotiation (putting up a header for thte
  57. >machine processible version and HTML for the human-readable version).
  58.  
  59. Will do.
  60.  
  61. Ron Daniel Jr.                       email: rdaniel@lanl.gov
  62. Advanced Computing Lab               voice: +1 505 665 0597
  63. MS B287                                fax: +1 505 665 4939
  64. Los Alamos National Laboratory        http://www.acl.lanl.gov/~rdaniel/
  65. Los Alamos, NM, USA  87545    obscure_term: "hyponym"
  66.